Hello
About a year ago I had a probelm after a few days Mikrotik dns woudl stop working untill reboot.
as it was mission critical I could not risk testing again.
Does anyone here have a mikrotik box set to primary dns that is under load?
Are you use 2.9 or 3?
Is miktotik dns bind? or is it their own?
Thanks
yes, same question in other wordsâŚ
how to configure (and is it possible) MT box to be nameserver, with authoritative answers only.
as much as i have used 3.9 version DNS is working properly.
and what about oldest versions, e.g. 3.0
allow remote requests: yes
primary dns: 0.0.0.0
secondary dns: 0.0.0.0
is that everything we have to do?
sure it working propertly, but⌠not as a nameserver. moreover, it works as a caching only server. i wonder if it is possible to do rdns, but⌠"Reverse DNS lookup (Address to Name) of the regular expression entries is not possible. You can, however, add an additional plain record with the same IP address and specify some name for it. " So, in one word, iâm affraid, we cannot use mt-ros as a nameserver fully.
Iâm afraid you canât use MT OS as a nameserver, cause it is a router.
Thanks
Yeah! We already said the same.
Since we have a Tik at every tower, does it make sense to use it as a caching server to speed things up a little bit?
If so, how much of the resources will it use, say on a 532 or 600? Is there a parameter to specify how much memory or resources go to it?
Paul
I have dns cache with remote request enabled in every network node. Like a pyramid. From my main router levels deep into the LAN and ultimately each cpe. Each CPE dns primary IP is set to the next âhigherâ router and this router to its next higher until we reach the main router which then looks up at the primary dns IP given from the ISP. It works flashing in a 100 client network and since network speeds for dns requests are much higher handled then the same from network to the internet (where ISP dns is located) it improves general browsing because probably 60-80% of requests are now cached in the network and thus closer to the client.
so you are taxing every routers DNS cache up the chain and not just one ? Seems like a waste to me. Think if 1 query or 10 queries is more efficient.
These days you should only query the root servers and not trust anything else.
Sam
Rudyâs approach appeals to me. Most subscribers tend to visit the same sites regularly and if the DNS request has to go no further than their CPE itâs quick and easy on the network.
However despite this I donât utilise the intervening routers for DNS as theyâre busy enough, so just refer the userâs CPE on to the gateway server which does DNS for the network.
fast dns answer acts as âfast start to opening webpagesâ - good QoS. ofcourse, if ârouter not very busy enoughtâ. we usually use power x86 pcs with hudge resourses - 3ghz cpu and big hdd storage for that. it manges wireless packets well and can serve dns and proxy cache also.
SweetSunday, ChangeIp:
I think we all are right in a way. Having each client look at the root gateway for dns resolvement will give the shortest response time when it is in brand new lookups.
On the other end, if each new requests has to be processed by each node (like in my situation) before it hits the root gateway that might consume a bit more time. But later lookups (within the time to live cicle of the cache) will reduce network traffic and gives the shortest possible return.
SweetSundayâs approach is a compromise in between.
What is the best solution will probably be depending on the actual use and size of the network. I think the bigger the network, and the more requests, the more benefit will be a solution that release the root server and reduce the network traffic.
I use all MT routers for APâs and back hauls and even the majority of CPEâs are MT. I have never had dns issues with these so reliability is not an issue here.
If I would have to give points I think SweetSundayâs approach is a winner in most situations.
I start to think of re config some of my setup by bypassing some of the back haul routerâs dns cache.
I have now virtually every router in the chain performing dns cache, that might be a bit overdoneâŚ
possibly you are missing my pointâŚ
How can the left side below be faster than the right side?
1 - each router can still run their own cache so downstream clients arenât going any farther than they have to.
2 - dns poisoning attacks are far more wide and trusting an ISPs DNS is not the norm anymore. dns poisioning can happen for malicious reasons, or because your ISP wants to make money on NXDOMAINs.
3 - funny thing is that that any initial query that Router A performs is almost guaranteed to timeout. If it takes more than 2-3ms then Router A should automatically requery using its secondary. So you queried and filled someone elses cache but you did it at the expense of showing a DNS not found error on someones browser.
You really shouldnât point a cache at someone elses cache that is pointing to another cache.
Sam, are you suggesting that we ignore our ISP name servers and just point our settings to our closest root servers?
Based on the drawing aboveâŚ
Interesting.. but the question then becomes⌠(and this depends into the combination of how wide your network is vs. how deep as well) âŚ
is the design philosophy to immediately serve the need to the customer in the most efficient (except looking at the next router in line) by taking the right side path OR is it to initiall make that first DNS request âthrough the chainâ so that next person that asks will NOT have to come all the way back to the âright side sourceâ next time.
the 2ms thing becomese a factor because we all dont have 2ms sequential hopsâŚ
not sure yet what the answer lies⌠a big factor would be the 1) the size of the cache you define and 2) the average TTL vs. how long it takes to "load the caches properly with requests up the line.
Lots of things to ponder⌠probably not going to be a one-size fits all answer
Paul, PDMNet
Based on the drawing:
It would suggest that requesting the root server direct would be so many times faster as the amount of ´inbetween´ servers are skipped times the time waisted at each ´in-between´ server.
but the dns-request package still has to pass all these ´in-between´ routers to reach the root. So this time is still waisted (routing/nat/mangle or whatever process has to be applied in each router the package travels through).
While if on the track down to the root the request could be solved by one of the servers somewhere down that track the answer can be send backwards and reach the initiator faster. The closer the server found with the info, the faster a request is solved and received back by the initiator.
Or, the bigger and ´deeper´ the network goes, the more advantage can be found in servers somewhere down the line.
I have to agree on Paul that one size doesnât fit all here.
Rudy
And here some more fuel for this discussion:
A pro for having only the root server handle all requests could be the following:
lets presume we call the root server level 1
under it you have lever 2 server and under that level 3 etc.
But actually under level 1 there can be two level 2 families, with each a level 3, level 4 etc.
Lets call these level 2A and level 2B. and their next levels 3A and 3B and so on. Families A and B only come across each other at level 1
In case we would handle all dns requests as much as possible in servers close to the requester then if a client in level 4A would request a page resolving this will fill the cache in each level server up to level 1.
Now this resolving is stored in level 4A and the client requests it regularly, after a time the ´higher´ cache levels drain this info since it is not been requested for anymore. The request is handled in level 4A each time.
If we now look to a level 4B client machine. If he would request the same resolving relatively shortly after 4A did, he will be given the result from 3B, which got it from 2B and that one from 1B etc. whoâs got it from the root, level 1 that happen to have this info for him waiting on the shelf. It was just delivered to 2A who gave it to 3A etcâŚ
But now the next day: 4B client wants to go to that same page again and finds the info for this is bled from 4B, 3B, 2B and even root level 1!
While 4A client has still been using it and 4A therefore still stocks it.
In this case the situation would have been better for 4B client if 4A client would have skipped 3A and 2A all the time and just each time asked root level 1.
It would still have been on the shelf waiting for 4B client too!
So, this is a plus for the system like explained by changeip!
[A downer on this policy would be the fact that now the cache will be much bigger than in a distributed network which will in time slow down the resolving in by the root server.]
Another brain wave:
What happens if the client stores the info in his machine itself? (Plenty of browsing accelerators do dns caching like windows does in explorer itself too.) Now info on the root will still bleed over time if no new requests are received. the client simply doesnât request because he knows the answer himself already!
So, yet again I would suggest that probably a best practise would be to have some cache performed in some important ´nodes´ in your network, together with the lowest level (client CPE, or even the PC itself)
It also gives some more redundancy in case the root server has problems.
Rudy
Hereâs an example of why caches arenât as useful with high speed links:
QUESTIONS:
yahoo.com, type = A, class = IN
ANSWERS:
â yahoo.com
internet address = 216.109.112.135
ttl = 300 (5 mins)
â yahoo.com
internet address = 66.94.234.13
ttl = 300 (5 mins)
So even Yahoo.com themselves only let you cache it for 5 mins.
QUESTIONS:
google.com, type = A, class = IN
ANSWERS:
â google.com
internet address = 72.14.207.99
ttl = 300 (5 mins)
â google.com
internet address = 64.233.187.99
ttl = 300 (5 mins)
â google.com
internet address = 64.233.167.99
ttl = 300 (5 mins)
Google.com even thinks 5 minutes is enough.
QUESTIONS:
akamai.com, type = A, class = IN
ANSWERS:
â akamai.com
internet address = 209.170.113.15
ttl = 20 (20 secs)
â akamai.com
internet address = 209.170.113.9
ttl = 20 (20 secs)
â akamai.com
internet address = 209.170.113.31
ttl = 20 (20 secs)
â akamai.com
internet address = 209.170.113.30
ttl = 20 (20 secs)
â akamai.com
internet address = 209.170.113.7
ttl = 20 (20 secs)
â akamai.com
internet address = 209.170.113.8
ttl = 20 (20 secs)
â akamai.com
internet address = 209.170.113.17
ttl = 20 (20 secs)
â akamai.com
internet address = 209.170.113.14
ttl = 20 (20 secs)
Akamai.com thinks 20 seconds is necessary.
Okay ... you know that DNS requests automatically timeout and fail to the next after 2 seconds. You can assume by the 3rd or 4th level deep of DNS caches that every request to those above domains will fail at least once every 5 minutes.
Hilton - yes, only trust the root. Amazing how many DNS resolvers are changing their responses these days. When does a masked NXDOMAIN start to break things? SMTP server trying to determine if a domain exists? Well they all exist when you use your ISPs cache. Sitefinder all over again.
WirelessRudy - Try 'ipconfig /displaydns' in windows. It already is caching itself. Run it a few times and check the TTL.
Samchangeip:
May be you can teach me more⌠this is a interesting tread..
You show that yahoo and google only allow to store a resolving in cache for max. 5 mins. if I understand well?
But when I look in my cache of my main gateway, (which is my root cache server) I see hundreds of name translations being cached.
[Two types though, type ¨A¨ and typy ¨CNAME¨. I donât know exact the difference but thatâs another question actually.]
But the point is that most of the translations carry a TTL of many days and counting down. The most is almost 7 days meaning in my opinion most of the translations stay in cache for 7 days?
You show that ¨Akamai.com¨ only allows their translation being solved for 20 secs. Why is this that short? Do they swap IPâs that often? I can understand that big servers like google and yahoo might have reasons to work with several IPâs for their servers so the dns has to be kept updated as much as possible.
But Akamai? Why would they want you to update your cache every 20 ms???
Okay ⌠you know that DNS requests automatically timeout and fail to the next after 2 seconds. You can assume by the 3rd or 4th level deep of DNS caches that every request to those above domains will fail at least once every 5 minutes.
Are you meaning to say that a dns request to a dns cache takes 2 seconds? It should be 2ms? And even then, is 2ms not a bit slow and is it also not depending on the size of the cache? And the speed of the medium the cache runs on? Please some more clarification here.
Hilton - yes, only trust the root. Amazing how many DNS resolvers are changing their responses these days. When does a masked NXDOMAIN start to break things? SMTP server trying to determine if a domain exists? Well they all exist when you use your ISPs cache. Sitefinder all over again.
What do you refer to as root. You mean a root cache, like in my model. Or is the root here a BIND server you run yourself, iow a real dns server?
The rest of the remark I donât understand at all. Maybe Hilton understand what you mean, but not me. And if I donât probably some other readers donât. We all have different levels of skills and knowledge. So can you please be more specific here and explain what you mean. It would make you a nice teacher!
WirelessRudy - Try âipconfig /displaydnsâ in windows. It already is caching itself. Run it a few times and check the TTL.
Well, tried that. The list stays the same, even if I did flush the cache (ipconfig /flushdns) and when I tried to type some new urlâs in my browser I donât see them coming up in this list neither. So am not sure what this list now exactly is. And therefore not sure what you are trying to tell me here.
Sorry, you must think I am not very smart, to start a discussion and then donât know what underlying basics might mean. But thatâs my way of learning. Start a discussion and during the process get new info and knowledgeâŚ
So, keep up the good work and we all benefit.