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?

as much as i have used 3.9 version DNS is working properly.

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

Seems like a waste to me.

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.

Seems like a waste to me.

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.

[quote="changeip"]
These days you should only query the root servers and not trust anything else.
[/quote]

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.

Sam

changeip:

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.

Hi everyone -

I don't usually wade in on these spirited discussions but felt compelled to thow in my 'two cents worth' this time.

In my current setup I use caching at the CPE and the AP. Next stop would be major backhaul 'intersections' where we use mostly PC based MTs. They have the memory and cpu power to cache large amounts of data without slowing the process down. Failing a lookup in any of these three devices, our DNS server is next and then the Internet Root DNS servers. (Rudy - root servers are THE DNS servers for the entire Internet - that is what Change-IP was talking about).

I have tried several methods on singular nodes, monitoring traffic, counting requests, counting bytes transferred for DNS requests only so that I could compare apples to apples and oranges to oranges - meaning different methods on the SAME nodes for a long period of time - in my case two months per node per change. My findings show (for our network now) that caching in the way I described above is very efficient and fast. That like wirelessrudy mentioned - many folks tend to use the same sites, once the initial request(s) are made, the info in cached locally (CPE) and as such is very fast for the client to retrieve. Initial requests may or may not still be cached - just depends on the cache and the timeout for a given site/dns entry. But I can say that for us this methodology seems to be the best mix.

R/

Well, as a result of this discussion going to alter my network setup slightly. CPE's, their AP and important nodes in the network and ultimately my main router are going to be cache server. This means effectively a cut down in 50% of the in-between servers and thus reduction in the track any new request will have to travel over my own network.

Indeed, having your own dns server (BIND?) is a good thing to have in a ISP's network. It's records will always be up to date, no matter if it has been asked for from within your own network. It will probably boost dns performance, on new dns requests. I still have to set one up, still need to do my homework on that.....

the remark changeip made towards Hilton I still don't understand clearly though.
If he just mend to state that ISP's dns servers are not always reliable I have to agree on that. That's why I now use an ISP's dns server which connection is apart from dns not used for browsing etc. This ISP has a good reliable and fast dns resolving, which couldn't be said from the ISP serving my bandwidth.

This ISP has a good reliable and fast dns resolving, which couldn't be said from the ISP serving my bandwidth.

Create your own DNS servers (at least two) to serve fast and reliable resolving, as you wish. Hosting your own domainnames and your own ip-address mangement also requre that.

Futhermore, you can sevre domainnames and create rdns records to serve RELIABLE resolving. And atlast in this case serving will be FAST, because all your custommers will be "good-connected" with your nameservers by default. Or much better than with your "nearest" ISP's nameservers at least.

If you are not agree to create 2 nameservers, you have to cahe your isp's resolvs by "caching only" bind or mt-ros, but this is slower and not everytime reliable.