Setting up Samba4 internal DNS forwarder to try multiple DNS servers

Our network setup until recently was that we had a Samba4 server acting as a DNS server for a few internal names, and forwarding to our main router for everything else (i.e. stuff on the internet.) Our main router, a Dlink DI-624, was happy to forward these requests to the appropriate DNS servers, which it would obtain from our modem.

Well, that worked great, without hiccups, until the DI-624 died. Our new router does not have DNS forwarding, so for the moment I took the primary DNS server from our internet connection and put that in smb.conf on the dns forwarder = line where our D-Link's address used to be.

My main beef with this is if our ISP changes that primary DNS server, which they have been known to do a few times a year, we have internet downtime and general confusion until this is figured out, and even once it is, we have to restart Samba which interrupts our fileshare in the process (more downtime). All this for something our old router just neatly took care of.

Unfortunately whether with spaces or commas dns forwarder in smb.conf doesn't seem to take more than one argument. I don't want to run BIND if I don't have to, but if it's simple enough I wouldn't mind switching from Samba's built-in internal DNS if it helps with this issue.

Is there some way to have CentOS grab current DNS server settings from our router and update smb.conf with them? Or at least let me list a bunch of DNS servers to try? Or better yet handle things automagically like our D-Link used to?

Kev

Posted 2013-11-25T18:37:25.757

Reputation: 1 069

Answers

Solution 1. get a cheap new router - it is higly unlikely your brand new $30 router won't have DNS forwarding function. Check the product specs before buying! It's also strange your new router does not have DNS function - did you check manuals and configuration interface thoroughly?

Solution 2. use google's public dns forwarder. it's quite ok (namebench tests claims google's distributed dns system is 266% faster than using my local bind9 caching-only service) unless you're concerned about privacy (about the fact that google might or might not collect your queries)

and at last, if the OP considers isc bind is too much overhead then maybe a light resolver like dnsmasq or unbound might come to help

Costin Gușă

Posted 2013-11-25T18:37:25.757

Reputation: 637

Re: sol1, yeah, I'm surprised our ISP's standard router+modem combo (2701hg-g) doesn't support DNS forwarding. Re: sol2, That's an interesting page...8.8.8.8 sounds like a nice option, but what's with all the errors it reports? – Kev – 2013-11-26T18:01:59.000

Also it gets my primary DNS wrong and doesn't allow me to change it, so I'm not sure I trust the numbers... – Kev – 2013-11-26T18:12:16.247

I don't see what errors are you referring to. if you talk about the namebench it's just a wrong header in that page and you have to scroll a little bit down to see the results. – Costin Gușă – 2013-11-27T20:37:32.457

Yes, the namebench--it's in the header but also in the results, numerous "incorrect" entries. – Kev – 2013-11-27T23:52:56.787

Went with Solution 1 here. – Kev – 2014-01-04T02:01:08.583

you can install a bind instance, set it to forward to whatever list you like in named.conf.options, and then point samba to it. you don't have to replace anything, just point samba to bind, and bind to whatever list of servers you like.

the only downside is that now your dns is inside your firewall, and you will likely have to open a hole for forwarded queries to respond through.

Frank Thomas

Posted 2013-11-25T18:37:25.757

Reputation: 29 039

he does NOT want to run bind :) that's clearly stated in the question – Costin Gușă – 2013-11-25T20:26:38.427

he said he did not want to replace samba resolution with bind, which isn't necessary. I've updated my response to clarify that point. thanks! – Frank Thomas – 2013-11-25T20:32:52.580

if the OP considers isc bind is too much overhead then maybe a light resolver like dnsmasq or unbound might come to help. – Costin Gușă – 2013-11-25T22:42:10.097

Could you expand on "you will likely have to open a hole for forwarded queries to respond through"? Doesn't it work like every other outbound request? – Kev – 2013-11-26T18:03:22.757

1UDP is hard for state-full filtering to deal with, because it is not connection-oriented as TCP is, and thus has no flags that let the NAT wall know that its part of an established connection starting from the inside. the state-full packet filter will try its best to make flows together based on the timing and source/destination addressing, but can't always make the determination that the server response is pursuant to a request made from inside. to make sure you get all your responses, you usually have to open a hole on UDP\53. – Frank Thomas – 2013-11-26T19:13:54.467