Secondary DNS feature

existenz

Verified User
Joined
Jul 18, 2003
Messages
542
Location
/dev/null
I know this has been discussed but not lately to my knowledge. Do you think you could add in the skin the ability to setup secondary DNS? I know this should be a pretty easy feature to add. It would be great if it was just in the admin area?

This seems like a very populary feature to be added, I know by our customers and I am sure other DA users.
 
I'll third the request...

and add another...

See my new thread :) .

Jeff
 
Robert's Rules of Order says no.

But of course they also say I can't "third" a nomination.

Jeff
 
John any thoughts...I know you said after backup's but just wondering if we could see this in the next release to so? I really think this is most overlooked features :-)
 
Hello,

We're just doing the admin backup now/next release .. so it will probably follow that.

John
 
How will that work John?

I already run secondary DNS by running bind on a VDS with slave zones setup. I type them in manually currently, but I've almost finished a PHP class for managing them via a web interface. The rest is simple... the default DNS are setup to use the slave DNS server.

How it affect my current setup?

Thanks,
Matt :)
 
Not too sure yet.

I was basically thinking of having an option to enable in the admin settings (or somewhere) such that you enter an IP, username and password of another DA server (admin) ... and DA would send all DNS updates to that DA server as well. You could set it up 2 directionally so that they each shared each others dns settings.

John
 
John,

Please don't do anything complex.

The best first step would be to allow the setup of a master DNS zone (as you have now) or a slave DNS zone on the DA machine.

That way any DA machine could be used for either master or slave DNS. Slave DNS would have to be set up manually on the machine hosting the slave DNS zonefile.

This would get us started.

I'd strongly suggest waiting for my scripts, since most of us run multiple servers with multiple control panels, and my way would allow any control panel to master or slave DNS for any other control panel; it would be most configurable.

Thanks for your consideration.

Jeff
 
Sure, I'll wait. I'll definately consider a easier way of doing things :) I'm aiming towards automation.. so if a User adds a second domain, it would be nice to automatically have it up and running on both machines. I'll hold off for the time being to see what you have in mind with the scripts :)

John
 
I already have slave DNS running as you describe Jeff - it's very easy to implement. What I need is a way for the slave zones to be added automagically to the second DNS server when a user adds a domain.

Perhaps there could be a 'DA DNS' daemon that could run on the second server and wait for commands from the main DA server.

Thanks,
Matt :)

Edit:

What are your scripts Jeff?
 
We're working on something much more generic that'll work no matter what system you've got, DA or other, as the master and as the slave.

But John and Mark will still be able to make it work for them and for us with DA if they wish.

That's the simple beauty of it.

It's a project we've been working on as an open-source project to the entire BIND-using community.

I'll make a formal announcement shortly in the 3rd party forum.

But in the meantime here's how it works:

One time setup on master DNS server: create a "namedftp" ftp user; this can be done inside or outside of DA or any other panel.

On the master server, multiple times each day (we use six by default) a cron job moves a copy of /etc/named.conf to the namedftp user home directory, renamed as 00.11.22.33.named.conf (where 00.11.22.33 is the IP# of the master server), where it can be gotten by ftp.

On the slave server, multiple times each day (we use six by default) a cron job does the following:

Get the named.conf files from all the master servers it's slaving, into a temporary directory.

Convert them from master format to slave format (there are two basic formats for master DNS and it's easy enough to test for them and convert them.

Once it's done with all the files, it'll concatenate them together into a single temporary file, do a search for duplicates; if it finds any duplicates it'll remove them from all the indiividual files and report them to the admin, who will have to figure out where they should be and fix the masters by hand, or notify the admins of the masters.

Then move the individual files to a /var/named/include directory

Then rebuild /etc/named.conf if necessary to have include directives for all those individual files.

Then restart named.

It's really quite simple, and it doesn't depend on DA specifically.

It's been delayed as I've worked on other projects but I've gone ahead and gotten someone work with me on it as an open source project.

It should be ready soon.

Jeff
 
jlasman said:
But John and Mark will still be able to make it work for them and for us with DA if they wish.

No offence intended Jeff, but from my point of view your post seemed a bit dictatorial.

What benefit does your system have over the normal Bind notifications system using slave zones? It seems that your system is indeed more complicated - requiring FTP, cronjobs etc it seems much messier than simply having a tiny DA daemon on the slave DNS server which adds and removes zones from the named.conf on the slave server. Heck I could even code the daemon in PHP, I've finished the PHP class for adding/removing slave zones. I was going to implement it myself by adding a script to the DA scripts directory which is called up when a user adds or removes a domain.

Your project sounds interesting and I'm sure it'll be a benefit to many, but for DA, why not use a small DA daemon on the slave server?

Best regards,
Matt :)
 
thoroughfare said:
What benefit does your system have over the normal Bind notifications system using slave zones?
If you're aware of any system built into BIND that enables it to tell another server to slave it's zones, please tell me. Also please tell the bind developers at isc.org.

They assure me that there is no method built into BIND that allows one BIND server to tell another BIND server which domains to slave.

My system is a simple one, to tell BIND servers what domains to slave.

Sure, you can easily log into multiple systems and tell them what domains to slave if that's what you want to do.

Or you can have DA do it for you.
It seems that your system is indeed more complicated - requiring FTP, cronjobs etc it seems much messier than simply having a tiny DA daemon on the slave DNS server which adds and removes zones from the named.conf on the slave server.

And how would it know which domains to add? You've got have a way to communicate between the two servers. My method (thought out by several people in brainstorming sessions) works simply, and it works whether you've got multiple DA systems, or other systems (Plesk, RaQ, CPanel, H-Sphere, etc.), or even stand-alone systems.

But maybe my system is too complex (for example, it allows for continued slaving of systems that disappear from the 'net). Please come up with a better one; I'm certaily willing to listen, and that's the beauty of open source projects; if you don't like what I'm doing, please do it better.

I hope the DA staff will consider my ideas; if they don't, then that's okay, too. Since most members of the open source community who have to slave DNS aren't running DA, there's still quite a bit of interest in my idea.

Just like my SpamBlocker and VirusChecker, use them or not, as you see fit.
Heck I could even code the daemon in PHP, I've finished the PHP class for adding/removing slave zones. I was going to implement it myself by adding a script to the DA scripts directory which is called up when a user adds or removes a domain.
Please don't let me or my project stop you.
Your project sounds interesting and I'm sure it'll be a benefit to many, but for DA, why not use a small DA daemon on the slave server?
As I wrote above, that daemon has to get the list of domains to slave somewhere. It has to communicate over the 'net. If you and/or DA staff want to implement some proprietary to DA method rather than an open source method, that's fine with me.

Jeff
 
jlasman said:
If you're aware of any system built into BIND that enables it to tell another server to slave it's zones, please tell me. Also please tell the bind developers at isc.org.

They assure me that there is no method built into BIND that allows one BIND server to tell another BIND server which domains to slave.

You misunderstand me. Surely you know of the Bind notification system... where if a domain name has a slave zone on the secondary DNS server, the secondary DNS server will look out for new serial numbers and mirror the settings of the master zone. It's how I have my slave DNS configured.

jlasman said:
My system is a simple one, to tell BIND servers what domains to slave.

Sure, you can easily log into multiple systems and tell them what domains to slave if that's what you want to do.

Please read my posts. I am suggesting that DA code a small daemon which can run on a secondary DNS server, and listen for updates from the main DA server. DA can use some kind of remote access key or authentication system to interact with the DA-coded daemon on the secondary DNS server, and notify it which zones/domains to slave.

jlasman said:
Or you can have DA do it for you.

I fully intend to have DA do it for me... rather than using some complex scipt plus FTP system. Not to mention the fact that FTP is unsecure, so someone could steal the password and upload any DNS data they liked.

jlasman said:
And how would it know which domains to add? You've got have a way to communicate between the two servers. My method (thought out by several people in brainstorming sessions) works simply, and it works whether you've got multiple DA systems, or other systems (Plesk, RaQ, CPanel, H-Sphere, etc.), or even stand-alone systems.

See my comments above... the domains to add would be communicated securely to the mini-DA daemon.

jlasman said:
But maybe my system is too complex (for example, it allows for continued slaving of systems that disappear from the 'net). Please come up with a better one; I'm certaily willing to listen, and that's the beauty of open source projects; if you don't like what I'm doing, please do it better.

I appreciate your project, but I simply think that for DA (and remember we are in a DA forum, not a Bind forum), then we should use a DA daemon. If people want to use your scripts, they could simply disable the DA option and use your script instead... no biggie.

jlasman said:
I hope the DA staff will consider my ideas; if they don't, then that's okay, too. Since most members of the open source community who have to slave DNS aren't running DA, there's still quite a bit of interest in my idea.

Jeff, again, I don't doubt that people like your idea. My point is that from the tone of your posts, it seemed as though you want your script system to be implemented as a standard DA install, rather than havingJohn code a more secure and less complicated solution (IMHO).

I could release my PHP too as open-source, add authentication schemes to it etc, and it would add domains to be slaved to the secondary DNS server securely and automatically. But I doubt DA would want to use it... unlike other control panels, DA is hardcoded in C and seems to avoid scripts where possible. I'm positive that DA wouldn't want to use my script either. It's not your script that I'm pulling apart, it's the idea of using it as the official DA solution to slave DNS.

jlasman said:
Just like my SpamBlocker and VirusChecker, use them or not, as you see fit.

People will be able to choose to use them, but I don't think that your slave DNS scripts should be the official DA solution, as your earlier posts suggested.

jlasman said:
As I wrote above, that daemon has to get the list of domains to slave somewhere. It has to communicate over the 'net. If you and/or DA staff want to implement some proprietary to DA method rather than an open source method, that's fine with me.
[/B]

I know it needs the list of domains - it'd receive them from the main DA server. I'm not suggesting my method is fullproof, I'm sure John will have a much better idea... I just don't think your solution is the answer for DA.

If you need a secondary DNS server which can receive notification from several control panel systems, I don't see why the DA mini-daemon couldn't work with your script.

I hope you understand my view Jeff, please do read everything I've written. It's not an attack on your script, but I'd rather not see such a solution introduced on my DA server. I'd like it to be much simpler, and more secure.

Best regards,
Matt
 
Hmm.. mini-daemon? ... sounds... like work :)

I think if a daemon would exist on a 2nd server, it would be another DA daemon for admins with 2 DA servers... but I'm sure not everyone would go for that. Plus having extra open ports listening should be avoided when possible..

So... perhaps 2 methods could work in the future:

1) Jeff's scripts will do there thing for servers that do nothing but dns for another (or many other) servers (non control panel probably). Nothing (or very little) in DA would really need to be done at all.

2) If the admin has a 2nd DA server, the 2 copies of DA could talk to each other, distributing and sharing dns info. This would be aimed more towards the whole "clustering" idea, with a few servers doing full hosting.

Nothing is in stone, but the simplest/cleanest answer is generally the best. Keeping things in script form (non-hardcoded) is a good idea for flexibility among admins (plus less work for me :))

But 2 different cases might need 2 different solutions.

John
 
I'm not really sure how having a mini-daemon would create extra unnecessary ports... since having an FTP server running for a script like Jeff's would mean open ports anyway.

The daemon would be very small... the most difficult part would be the authorisation.

Depending on when DA can implement this feature, I'm going to code my own PHP solution when I have more time I think - I'll let you know how it goes.

Thanks,
Matt :)
 
DirectAdmin Support said:
2) If the admin has a 2nd DA server, the 2 copies of DA could talk to each other, distributing and sharing dns info. This would be aimed more towards the whole "clustering" idea, with a few servers doing full hosting.

PS I like the above idea... saves resources :)

Matt
 
Back
Top