Hello,
is here anybody who was trying to set up slave DNS server and things around zone transferring? Im using BIND on my Ubuntu 20.04 and i would like to have Mikrotik as secondary slave DNS server. Nowadays, Is it even possible?
Many thanks
No chance. You can just define static records of few selected types and that’s it. No zone transfers, no support for authoritative server whatsoever, …
As far as I see MT DNS , it is not a full DNS server (zones/master/slave/delegation/root-hints/forwarder DNS) but rather a DNS forwarder with also local static entries.
Never been able to define a zone or to be SOA, or to transfer a zone as secondary server, or to delegate a zone to a specific server … with MT DNS.
Correct, it’s not there, probably never will, and it’s not even bad thing. I’m big fan of having many features, but given how MT likes to make own implementations, currently it doesn’t seem realistic that they would add full-featured DNS server. They could relatively easily add few basic things for authoritative server, but then there would be endless complaints about missing features from those who got their hopes up too high. But if you really want it very much, in near(ish) future there should be support for containers, so that would be a way for real DNS server on RB.
The default cache time for the internal DNS caching server is 1 week, so any names in active use should be in the cache at the time when the main system goes down, such as to reboot after a kernel upgrade.
In actual practice therefore, what would be the practical difference?
Keep in mind that the notion of master/slave DNS relationships predates high-capacity DNS caching. In a time when you might want to dedicate a whole machine to DNS, you couldn’t expect your switches to have DNS caches at all, and when they did get them at the first, they were small. Now we have more RAM in our cheap switches than we used to have as disk in the early big-iron DNS servers, back in the days when RFCs had three-digit numbers.
My point is, cache vs slave is a distinction without a difference in many practical cases.
Mmmmmm … there are other uses of secondary DNS zone transfers than just caching. It combines multiple independent zones from your other managed networks.
Not for home use, but common in an enterprise. But yes you would use full blown servers for the DNS. (e.g. combining different “forests” like develop/stage/production, or HQ and remote offices)
However needed it in the Fortigate as default firewall DNS for the guest network in the city hall, pointing to some local but not public servers and services in the office network, for visiting guests.
(Better than zone transfer and maintenance “by screen/keyboard” interface.)
DNS slave is not simple cache. It is authoritative server that can serve queries indefinitely, without need to refresh data from master server. The only functional diference between (single) master and (multiple) slave servers is that DNS admin always changes data on master DNS server which then notifies slave servers that zone data was changed (and slave servers then initiate zone transfers to update their databases).
So slave servers are not so much performance feature, they are more a matter of redundancy. Sure thing, performance is also welcome.
Caching can be quite aggressively performed by any entity working with records (either clients or forwarders) … TTL setting allows that.
I’m aware of that, but now you’re getting into edge cases. I submit that most uses of zone transfers are for redundancy only, which caching also solves provided the cache is primed prior to the primary data source going offline.
However needed it in the Fortigate as default firewall DNS for the guest network in the city hall, pointing to some local but not public servers and services in the office network, for visiting guests.
In such cases, can you not make the main DNS server do that, then rely on caching for redundancy over the top of that?
Sure, but my point is, what functional difference is there between a 1-week cache time and “indefinitely”? What real-world condition would you have where the main server is down longer than that, allowing all cached DNS entries to expire? You should be able to have a new machine up on brand new hardware and restored from backup after a meteor strike faster than that.
DNS admin always changes data on master DNS server
I’ll grant that while the main DNS server is down and you’re running on the cache alone, you can’t change DNS entries, but here again we have to weigh the risks. Normal downtime is going to be on the order of 2-5 minutes, a server’s reboot time. DNS changes can almost always wait that long.
slave servers are not so much performance feature, they are more a matter of redundancy.
A cache that’s fully-primed also provides redundancy. Names that are in regular use stay in the cache, with each new lookup resetting the cache timeout for that entry.
I went looking for other major networking providers’ capabilities in this area, and of Cisco, Juniper and Aruba, only Cisco seems to provide a full DNS server on their routers. I think it’s amazing the extent to which MikroTik competes on that level for the price, but when they fall short, I don’t think less of them for it.
Don’t recursive resolvers require authoritative answers? I’m not sure if they enforce it, but at least I do remember that authoritative servers should mark their answers as such. Cache won’t do that.
Your best bet for this is wait until docker is stable and you move to ROSv7 - run a full DNS server in a docker container.
Well, depending on how you manage fetching data from master DNS server the cached data life time can be significantly less than 1 week. Usual DNS servers will cache replies according to TTL received from upstream servers. If upstream server is master DNS server of a zone, then all entries will be received with full TTL. At certain point of time. At that time TTL will start to decrease. So it might decrease to a fraction of original TTL when master DNS server disappears. Which means usable lifetime of entries in cache will be much less than a week.
Additionally normal DNS servers will only cache entries passing through them, they have no means of knowing which other entries exist in certain domain. Which means that usually servers only cache a fraction of whole zone. So if you wanted to keep TTL fresh and seed cache with whole zone, you’d have to run a script on the master DNS server, skimming through master config and request resolution from caching DNS server. And do it quite often to keep cache fresh.
Your other arguments are moot as well. It might seem that caching (in stead of running proper slave DNS server) would work, but sooner or later there would be some problems. The real solution is simply to run a full-featured DNS server as slave. If your router has resources to spare, then it would be nice to run a good DNS server in a container.
Quite a DNS basic course here 
. Don’t know if recursive requires authorative answers. Only ran into issues with Fortigate when the “alias” and the A-record where on different DNS servers.
For the zone extraction try a “nslookup ls ” on your or other DNS server, it will mostly be refused. So skimming wan’t be easy.
And what with DNS round-robin answers and cache ? What after reboot? How long to populate the cache? If the DNS is used for internet, how many new entries per second in the cache?
MT has no “High Availability” like a cluster setup for the routers. I see VRRP, and ROS7 is starting with connection tracking synchronisation.
That’s not full redundancy (firewall, config, session sync), not even an “active-passive” cluster with auto failover. DNS redundancy must be better than “cache”.
Main router will remain Draytek Vigor cluster for now, all the rest is MT. (Fortigate too expensive for non-professional use)