Which dns would you recommend?

graudeejs

graudeejs

I wonder which DNS should I use. I'm noob at this, so I was hoping some more experienced admins could aid me a bit.

Currently I'm thinking about dns/bind vs dns/powerdns

My server will host some sites this is primary reason why I want to use DNS server.

I want DNS to work with PostgreSQL, be easy to configure, secure and fast.

If you recommend which version would you recommend?


All your experience is much appreciated.
(please answer with more than 1 short line)
 
All I can suggest is to pick one, try it for a while. Then try the other one. Both can do what you want and each has it's own quirks or things to consider. I do have to admit I use BIND and I'm not too familiar with powerdns. My choice is mainly because I've always used it, long before powerdns existed. I should try powerdns someday though, as I'm a little chauvinistic and powerdns' origins are Dutch :)

That said, BIND with a postgresql backend isn't all that common. AFAIK it's still mainly used in the 'traditional' way with zone files. Biggest bonus is that you can find a huge amount of information on the Internet about running and maintaining BIND. Zone files are just plain text files which makes it really easy to script something for it. And those types of scripts are relatively easy to find.

But if you're dead set on the postgresql backend I would probably try powerdns first.
 
How zone info is stored? in one or many files? Can it be dynamically changed?

I ask because I don't want to spend week/weeks to figure out how it works just to find out, that It doesn't suit my needs.
 
I vote for nsd/unbound

I prefer the combination of nsd and unbound (both in ports), myself. They're not point-and-click easy and don't serve zones from databases, but they're both nice, small servers that work very well.

I've never understood the desire for complicating a DNS server with the installation and maintenance of a database server. Text zone files are so handy: they're small, they replicate well via rsync, and they are easily subjected to version control.

Of course, I've never administered a *huge* name server, so maybe my bias against database integration is ill informed.

In any case, I've used nsd/unbound for several years now on some small servers, and they've served me well.

Of course, as others will point out, you can't go wrong with BIND, either.
 
I will later develop fronted (or use some existing frontend) that will let user to update DNS records, so I think that using database will be easier, than using text files, but I might be wrong

If after updating/adding/removing files DNS server automatically update it's states, then why not using simple files, but if not, then you can see advantage of using database {at least I think so}

about version control.... I control versions of all files on my system with ZFS snapshots :D
 
killasmurf86 said:
How zone info is stored? in one or many files? Can it be dynamically changed?
Click to expand...
Each zone or subdomain will have each own file. They can also be dynamically changed. I have DHCP and DDNS working fine. As for scripting you just need to 'freeze' dns, update the zone file (and serial number), then unfreeze it. No need to restart.

I ask because I don't want to spend week/weeks to figure out how it works just to find out, that It doesn't suit my needs.
Click to expand...
True but I can't tell you what your needs are ;)
 
IMHO using PostgreSQL for a few zones is a huge overkill ;)

If you only have to serve zones, in other words, your nameserver will be an authoritative only one, you have more choices. Have a look at Dan Bernstein's tinydns.

Investing some quality time on Bernstein's djbdns will give you a nice pay back.You will really understand what DNS is all about. Even if you later switch to another nameserver, you will have a far better understanding of what DNS, then jumping into using a complicated beast like BIND directly.

Although I have not used it yet, for an authoritative only nameserver, nsd is also a nice alternative.

"Learning BING", isn't Google the de-facto standard? Yes, I know you meant BIND, just couldn't resist ;)
 
killasmurf86 said:
about version control.... I control versions of all files on my system with ZFS snapshots :D
Click to expand...
Text files are easier to version control and maintain using other methods. Quicker to access and restore but more importantly, human readable. Current job has a complete website, including a zillion backend scripts and config files in CVS. You tag a certain version of the code and it gets released on the correct production server. Brilliant. Easy to roll back too when it turns out you didn't test it properly x(

As long as your zones or the number of zones you manage isn't too big a database backend will most likely be slower to access then a simple file on disk.
 
about version control.... I control versions of all files on my system with ZFS snapshots :D
Click to expand...

I love ZFS as much as the next person, but it can't do stuff like
Code: 
git log named.conf
to tell you what changed and who changed it.

I can't tell you how many times a "git log" or "git diff" (or the Subversion or RCS equivalents) have saved my bacon when something broke, whether it was me who did the breaking. :)
 
Dice's point about info availability for BIND is dead on - there's a TON of it out there.

Having plain text files is actually a good thing IMO. They can be changed from the console or over a telnet session very easily without relying on a front end. You also don't have to worry about your database becoming corrupt. (Not that that has EVER happened... ;) ) Just about every scripting language known to man is able to output text to a file, so it's easy to write a script to change them if you need to. Webmin has a front end for BIND, but I haven't used it and so cannot comment on how it is.

I use BIND on my system and it's quite easy to set up, even though I really don't understand most of how DNS works. /etc/namedb/named.conf has a reference for each of my zones to a text file in the master subdirectory, each of those files contains information about the IP of that domain.

Code: 
$TTL 3600
mydomain.com.  	IN  SOA ns1.mydomain.com root.mydomain.com (
                                              2009113001
                                              10800
                                              3600
                                              604800
                                              86400
                                              )
                  IN  NS  ns1.mydomain.com.
                  IN  NS  ns2.mydomain.com.

                  IN  MX 10 pop.mydomain.com.
                  IN  MX 20 mail.mydomain.com.

                  IN  A w.x.y.z
localhost         IN  A w.x.y.z
ns1               IN  A w.x.y.z
ns2               IN  A w.x.y.z
mx                IN  A w.x.y.z
mail              IN  A w.x.y.z
imap              IN  A w.x.y.z
pop               IN  A w.x.y.z
smtp              IN  A w.x.y.z
www               IN  A w.x.y.z
webmail           IN  A w.x.y.z


Regarding versioning, the second line of the file (2009113001) contains the version of the DNS record. This is important because a DNS server will cache a name record and only refresh them when a newer version is available. (At least this is how I understand it to work from the research I did when setting up my server.) You can use whatever versioning system you want, but most use what I have above - YYYYMMDD followed by 00, 01, 02, 03, etc for each change on a given day.
 
I have read that MyDNS and PowerDNS can both be configured with an SQL back-end. This is from Jan-Piet Mens' excellent book entitled "Alternative DNS Servers"
 
I've been using MaraDNS for some time, I like it. It is simple, and "just works".

I dislike PowerDNS and their SQL configuration. Reasons for this should be obvious.
 
I installed tinydns, it seams nice.
For now I will stick to it, but currently I doubt that I will keep it permanently.


J65nko said:
Investing some quality time on Bernstein's djbdns will give you a nice pay back.You will really understand what DNS is all about. Even if you later switch to another nameserver, you will have a far better understanding of what DNS, then jumping into using a complicated beast like BIND directly.
Click to expand...
Thanks you, I really learned a lot from tinydns :)
 
You must log in or register to reply here.
Back
Top