DNS Forwarder Stable and faster than DNS Resolver!
-
I agree - OpenDNS definitely works with forwarder just fine.
I still have it configured in one place for keeping the kids off porn.
Works great as long as the kids are sort of on the slow side…. -
slow side ;) heheheeh Oh that is funny.. So guess its a special needs school? hehehehe
-
Nope - Smart kids. Special needs X-Wife…
You know the type.
-
By disable DNSSEC and enable DNS Query Forwarding I've got Success OpenDNS forwarding :)
So I was wrong :-X
And I'm happy because I really want use DNS Resolver without thinking there is a bug on it or is slow.
Thank you Johnpoz for finding my mistake.
And I don't care anymore for the first ms unless it's become 0 after caching.
Thank you guys your comment was very helpful :)
-
if your just going to forward and not use dnssec, your not actually using the resolver.. What feature of unbound are you using if you just forward and don't use dnssec? I would suggest you just continue to use dnsmasq that allows you query your ns in parallel and use the fastest response.
If you want to leverage dnssec, you just need to forward to ns that supports it is all. Opendns in their infinite wisdom has yet to support it.. Their idea is to use dnscrypt, which really only validates your getting the answer from them.. Doesn't mean the info you get from them is correct..
-
Unbound in resolver mode doesn't really come to its own until you have a sufficiently large number of clients on your network, for home/small business networks you're better off using Unbound in forwarding mode or DNSMasq.
-
While I agree if you have a large enough client base, the issue of couple extra ms of the initial query being resolved vs just forwarded and pulled from an existing cache goes away.
I would disagree that there are not advantages in resolving vs forwarding even for a small user base. I like to know that the info I got is from the authoritative server for the domain in question vs just getting something from some cache that could be invalid. I will live with the couple extra ms needed to do this, once your up and running and your cache gets populated you never even notice this. And you can always turn on the prefetch option in advanced to help keep your cache current to help eliminate the few extra ms needed to resolve vs forward.
Depending on what your looking up, its quite possible that even a cache as large as opendns does not have your item cached and has to either resolve it or forward it to a resolver, etc.
To be honest unless you have a really crappy internet connection, or your isp is doing something that prevents resolving your not going to even notice the few extra ms needed to actually resolve vs forward no matter how small your user base is. Using resolver mode is really the only way to be sure your getting dnssec support. While there are isp ns that do support it. There are also many that do not, etc.
-
I have 14 Pfsense servers with different type of hardware and Pfsense version with different ISP and different locations and the clients for each is between 100 - 300.
since I used the DNS Resolver our client complains about internet issues and slow browsing for sometimes.
when I change to DNS Forwarder and I used public DNS, these issues just gone, even the internet is more stable and everyone is happy now.
I still prefer to use DNS Resolver for security reason especially for the office but after find out why these problems appears with DNS Resolver
-
There are a ton of setting and advanced setting that can affect how well DNS resolver will work for you.
I have prefetch enabled.
harden DNSSEC
If you have frequently changing wireless clients, Register DHCP leases in the DNS Resolver might cause slowness?
-
Yeah reg of dhcp clients does cause a restart. This maybe clearly the cache? Would have to check that, but sure if its restarting dns would be offline during that period which sure could cause some complaints.
You would need to investigate some of the problem sites they are reporting, or if unbound is just offline. Do you see it restarting a lot in the logs?
Also where are these sites, since you need to talk to the authoritative servers. if the dns for the site blows or is on the other side of the planet from you and has a really short ttl that could be an issue.
-
I don't use Register DHCP leases in the DNS Resolver!
It's not right to choose the best settings for a single client then use it in large clients because it's not the same, especially the issues does not appears immediately, usually I find out the issues in the next day after complaining.
For the clients I use Captive Portal with Local User Manager and Per-user bandwidth restriction enabled.
for the offices without Captive Portal and the problem is the same for both.
As I mentioned before this issue start since i used the DNS Resolver but with Forwarder these issues not exist anymore.
there is something in the resolver settings or belong make it unstable.
-
I will enable the DNS Resolver in one of the servers and clear all the logs to start fresh investigate and monitor resolver to see what is going on.
Any advice for advanced monitoring?
I really appreciate the help and the time you've expended with me :)
-
Other than register dns, you sure your not using it? Its quite possible that setting is on out of the box. Did you purposely uncheck it?
The resolver is very stable.. If your having problems with it then you need to investigate the cause. Maybe the sites these users trying to go to have broken dnssec? Maybe the domain(s) nameservers are on the other side of the planet or just really suck and have a short ttl, etc.
Once an entry is cached it is no different than the forwarder. So if your having problem with dns lookups you need to investigate why..
-
The Register DHCP leases already unchecked is the same now!
I've noted something eals before disable the resolver and enable the forwarder this options DNSSEC , DNS Query Forwarding was unchecked.
Now the DNSSEC is checked and everything is fine until now and I still using OpenDNS but behind the resolver so the DNS Query Forwarding not checked and DNS Server Override not checked.
Also i test the namebench it sayes Primary Server 192.168.11.1 is Fastest.By now I'm getting the same results of DNS Forwarder without forwarding
-
"By now I'm getting the same results of DNS Forwarder without forwarding"
As we have gone over dude once something is cached your not going to notice any difference, anything you lookup from cache be it dnsmasq (forwarder) or unbound (resolver) should all be lan speeds, ie sub 1 ms..
If you wanted to truely benchmark overall performance of the forwarder vs resolver you would have log at the client level speed of resolving everything they query for, and you would have to let it run for a while to let your cache populate.
Once your cache is populated, uses should not notice any sort of different between using forwarder or resolver. Unless they tend to go to lots of sites that have shitty dns on the other side of the planet that takes you awhile to resolve. And then the ttl is like 5 minutes or something, so you constantly have to resolve it vs serving it up from cache.
If you have a significant user base, that builds up a decent cache of common sites your never going to see any difference. Maybe the 1 guy that hits site after the ttl expired might see a few ms extra delay in getting his answer… But who really gives shit if a site takes less than a second to resolve. Now if having a hard time in resolving that stuff is timing out then ok.. But normally your only talking a few ms between pulling it from some caching server that is 30+ ms away anyway vs actually just resolving it. Unless of course that domain your looking for ns is in china and your in texas ;)..
I really wouldn't expect to get much actual useful info out of namebench - its more designed to see who has better cache and who is closer when your pointing directly to say opendns or googledns or your ispdns, etc.
edit: Opendns does not support dnssec.. I can double check but everything I have read they do not support it. Much of the info I have found is dated.. Its simple enough to validate.. Let me check and will report back. So if stuff is working your prob just pulling from cache.. or not forwarding.
edit2: sure doesn't look like they support dnssec to me.. So as you see if I just use my local resolver it comes back with the dnssec info that I asked for and has the ad flag set.. When I send that query to opendns, no info back and notice no ad flag..
So notice the time from doing a full resolve with full dnssec 182 ms, vs asking opendns 119 ms - your really worried about 63 ms difference?? That is 0.063 of a second.. Come on... And the next person that asks that would get 0 ms.. Same as if it had come from opendns.. And keep in mind that even after that ttl expires.. if any of the NS are now cached in tree to get there, don't have to resolve those again, etc.
You should prob just stick to forwarding to your opendns.. Don't take it the wrong way, but someone using opendns and namebench prob doesn't have enough experience with dns to understand why those extra few ms don't matter in the big picture.. If I recall namebench was a google project - most likely real goal was to point out how googledns is "faster" than your isp dns so use it ;)
So user browser is going to cache, the os is going to cache - which are just asking another cache your local ns.. Which your just forwarding to yet another cache ;)
-
So, there is two bugs in the DNS Resolver:
1- forwarder mode doesn't works
2- The browsing processing is slowNo and no. 0 bugs here. The performance you're comparing is two vastly different things, yes there is higher latency when doing your own recursion with an empty cache. Enable forwarding mode if you don't want that.
Two, if you enable forwarding mode to something that doesn't support DNSSEC like OpenDNS, then you must disable DNSSEC in Resolver if you enable forwarding mode.
-
@cmb:
Two, if you enable forwarding mode to something that doesn't support DNSSEC like OpenDNS, then you must disable DNSSEC in Resolver if you enable forwarding mode.
Spot on: It had me baffled for quite some time, but this post gave the right solution.
