Secondary DNS feature

[existenz]

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.

[l0rdphi1]

I hereby second this request for secondary DNS functionality. :)

[nobaloney]

I'll third the request...

and add another...

See my new thread :) .

Jeff

[existenz]

Are we allowed to nominate our own feature request twice?

[nobaloney]

Robert's Rules of Order says no.

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

Jeff

[existenz]

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 :-)

[DirectAdmin Support]

Hello,

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

John

[thoroughfare]

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 :)

[DirectAdmin Support]

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

[thoroughfare]

So would there be a mini-me DA daemon on the second server?

:D

Matt

[nobaloney]

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

[DirectAdmin Support]

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

[thoroughfare]

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?

[nobaloney]

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

[thoroughfare]

Originally posted by jlasman
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 :)

[nobaloney]

Originally posted by thoroughfare
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

[thoroughfare]

Originally posted by jlasman
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.


Originally posted by jlasman
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.


Originally posted by jlasman
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.


Originally posted by jlasman
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.


Originally posted by jlasman
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.


Originally posted by jlasman
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.


Originally posted by jlasman
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.


Originally posted by jlasman
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

[DirectAdmin Support]

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

[thoroughfare]

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 :)

[thoroughfare]

Originally posted by DirectAdmin Support
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

[DirectAdmin Support]

I just don't want to re-invent the wheel when there are perfectly good (proven) programs that can be used with some really simple scripts :)

I'll be interested to hear how your script works out :)

John

[existenz]

What I have not figured out from all these posts is I personally don't care about entering the new zones manually. Its great if it did it automatically but I want to make sure that you don't need to enter a primary zone to make this work.

The other question to Jeff would be how does it reload the zone file if the master is down. Does it assume that the server is down and does not destroy the existing zone file?

My only thought from this entire thread is that we are worried about how to make this interact with other control panels and other DA servers. Screw it, currently we don't do anything else between two servers so why start now? When a version of DA comes out that can admin multiple DA servers then we can worry about this but lets keep it simple.

All we need to do is have a place to enter the domain, and the ip of the master servers. That would make it easy for everyone.

[nobaloney]

Well, at least we're finally seeing some interest.

My only responses to thoroughfare would be that I'd appreciate it if he'd show me the security holes rather than just allude to them, and also that I don't leave any ports open at all, contrary to his suggestion that I did.

To everyone else, I point out that there's nothing wrong with scripts, and there's nothing wrong with programs written in C.

The reason we (here) write scripts is severalfold:

(1) They're easier to write than C, and there's a larger base of people who know how to write them.

(2) It's easier for people to accept them, as most people can read through and understand a script a bit more easily than a C program, and many admins don't want to run 3rd party C programs unless they understand them well, so it's easier to get scripts accepted in the general community.

(3) Modern scripting languages work well, and work quickly, with little system load.

You'd be surprised how much of your linux/unix systems are implemented as various scripts in various scripting languages. For example, Majordomo is written entirely in perl scripts. Mailman is written entirely in Python scripts.

I apprceciate all the work John and Mark do for us, but I know they have a limited number of hours available every day, just as we do. I'm willing to take some of that load off them by creating Open Source solutions they, you and I can all use.

It may sometimes sound as if I'm arrogant; I often am, but I don't mean to be, and I don't mind being taken to task for it.

But please, when doing so, give me concrete examples of what you think is wrong with my ideas as well as my presentation, so we can all learn from them.

Originally posted by existenz
What I have not figured out from all these posts is I personally don't care about entering the new zones manually. Its great if it did it automatically but I want to make sure that you don't need to enter a primary zone to make this work.
Of course you (or DA) must create a primary zone on the master server.

Thousands of BIND admins currently use scripts to replicate the information to the slave server so they don't have to create new zones on the slave server; all my small project is, is an attempt to create a small Open Source solution anyone can use.

The other question to Jeff would be how does it reload the zone file if the master is down. Does it assume that the server is down and does not destroy the existing zone file?
My sripts don't touch existing zone files at all; BIND updates them automatically according to the times in the SOA record in the master zone, and that's set up automatically by DA using values which are generally reasonable.

My scripts will create a new include file for /etc/named.conf, and that new include file will contain a list of all the domains mastered on all the servers it's set up (once) to slave.

If during any one of the update cycles it can't get a copy of the list from a server that's down, it uses the last list it has. It will do that forever, until you, as admin, remove the server from the list of servers it's set up to slave.

My only thought from this entire thread is that we are worried about how to make this interact with other control panels and other DA servers. Screw it, currently we don't do anything else between two servers so why start now? When a version of DA comes out that can admin multiple DA servers then we can worry about this but lets keep it simple.
I still think my solution is simple. The fact that it works with all nameservers, not just DA servers, is just icing on the cake, considering many of us have multiple servers and not all of them are DA servers.

All we need to do is have a place to enter the domain, and the ip of the master servers. That would make it easy for everyone.
Note quite, for several reasons:

1) If your resellers or clients set up new domains or if you have automatic domain setup (Whois.Cart, ModernBill) then you may not know when a domain is set up.

2) If you do know, then do you really want to have to go to your slave server and set up domains manually?

If both of these conditions work for you, then yes, and if your slave server runs DA, then yes, a simple addition to the DA DNS screens would suffice for you.

And frankly, I do hope they set up such an addition.

And may I offer another suggestion if these conditions work: You can probably buy a Cobalt RaQ3 or a RaQ4 for in the neighborhood of us$250 - us$300, rebuild it with a RaQ4 restore CDROM, and do exactly what you want.

But for those of us who don't want to have to manually enter anything, my solutions appears to me to be quite simple, and elegant.

if you disagree, please give me some constructive criticism.

Thanks.

Jeff

[thoroughfare]

Originally posted by jlasman
My only responses to thoroughfare would be that I'd appreciate it if he'd show me the security holes rather than just allude to them, and also that I don't leave any ports open at all, contrary to his suggestion that I did.

Isn't running an FTP server on your secondary DNS box an open port?

I was thinking about your script last night. Perhaps you could use scp rather than FTP? I still don't think it'd be the best solution for DA's implementation of secondary DNS but it will definetly be of use to many bind users I'm sure.

John, I was also thinking about my PHP script - it could be even simpler. It could be run as a cronjob on the secondary DNS box and simply access the DA API and retrieve the list of domains and add/remove them to the named.conf accordingly. That way, there'd be no daemon or open socket, and it removes the need to use some kind of authentication system, since we could use DA's HTTPS.

Matt :)

[thoroughfare]

Originally posted by jlasman
To everyone else, I point out that there's nothing wrong with scripts, and there's nothing wrong with programs written in C.

PS Jeff, I wasn't saying there's anything wrong with scripts. I'm a PHP developer - PHP is a scripting language. My contention was that DA should implement a daemon to make it secure and 'less messy' if you like. The scripts idea is growing on me however, and I agree a daemon is probably over the top.

I felt you were being arrogant because it seemed as though you were trying to get the developers to use your scripts in an almost demanding way. Consider my point of view, having never heard of your scripts before, and then reading 'I strongly suggest [that DA waits for my scripts]'. Can you see that? I understand now how you meant it, and that you probably didn't intend it to sound like that.

My points before about your script system were:
a) I felt that it should be developed by DA themselves
b) I think using FTP to transfer the files is a bad idea because it requires:
i) an FTP daemon to be added to the secondary DNS box
ii) FTP accounts and cronjobs to be setup
iii) FTP is an insecure protocol

For me personally, I think I'm going to develop a PHP script that uses the DA API and updates named.conf accordingly (see my above post).

Sorry for any misunderstandings.

Matt :)

[DirectAdmin Support]

Just remember that no decisions have been made yet. :)
We'll try to have plenty of discussions to determine the best method for the majority.

John

[nobaloney]

Originally posted by thoroughfare Isn't running an FTP server on your secondary DNS box an open port?
Read my scenario again carefully and you'll see that the Slave DNS server doesn't use an FTP daemon; it does the FTPing to the DA box and then runs the "get" command. Maybe I didn't make that clear enough :( . My guess is that most webhosting systems already use an FTP daemon, and the purpose of my proposed system is to allow users of hosting control panels to to do slave DNS "automagically". I believe most hosting panels also run FTP daemons.

The insecurity is that if someone is sniffing your data they can find out your password.

That's true, but all they can get if they log into your master DNS server and "get" the contents, is your list of zones. Nothing else. And if the system properly sets up permissions (and it will) they won't be able to poison the system by adding or changing anything.

I was thinking about your script last night. Perhaps you could use scp rather than FTP?
I could, but I'm not guaranteed that everyone who uses a control panel has scp installed. Nevertheless it's a good idea; thanks. I think I'll offer it as an option.

I still don't think it'd be the best solution for DA's implementation of secondary DNS but it will definetly be of use to many bind users I'm sure.
It'll work for me :) . And probably for anyone else running multiple control panels.

John, I was also thinking about my PHP script - it could be even simpler. It could be run as a cronjob on the secondary DNS box and simply access the DA API and retrieve the list of domains and add/remove them to the named.conf accordingly. That way, there'd be no daemon or open socket, and it removes the need to use some kind of authentication system, since we could use DA's HTTPS.
From where would the DA API (on the slave DNS box) get the list of domains on the master box? That's the part of your plan I don't get yet. Is there a way to get it without (a) running a daemon on one of the boxes or (b) adding a program to the inetd or xinetd list?

Thanks.

Jeff

[nobaloney]

Originally posted by thoroughfare
PS Jeff, I wasn't saying there's anything wrong with scripts. I'm a PHP developer - PHP is a scripting language. My contention was that DA should implement a daemon to make it secure and 'less messy' if you like. The scripts idea is growing on me however, and I agree a daemon is probably over the top.
Sorry; I should have read your second post before replying; now I understand you were considering a separate daemon.

I think that's a great idea, when DA (the company) has the chance to to implement a multi-server solution.

But I certainly don't want to see them creating so many interim solutions that the final end product gets delayed, and that's what I'm afraid of.

I used to market a really great Windows-based email server.

It was a first version, written in Delphi.

The eventual plan was to completely rewrite it in C++.

Never happened, because the company got so involved in adding features to the first version.

I don't want to see that happen to DA; I want to see them be able to move along.

I felt you were being arrogant because it seemed as though you were trying to get the developers to use your scripts in an almost demanding way.
You're right; reading it over now, I see what you mean.

Consider my point of view, having never heard of your scripts before, and then reading 'I strongly suggest [that DA waits for my scripts]'. Can you see that? I understand now how you meant it, and that you probably didn't intend it to sound like that.
No, I certainly didn't.

Okay, let me introduce myself:

I'm Jeff and here's where I come from:

I founded my first (and one of the first, no one around now seems to be sure of the exact numbers) webhosting company back in late 1994, when you could only get one IP# per machine and only one domain per IP#.

(Sold it in '95, but that's another story.)

Before that I've been on the 'net since long before it was the 'net, been using and creating software since Unix ran on TRS-80s, and was President of an international guild of database programmers for three terms running.

Developed business programs for the TRS-80 Model I and was for a time VP of Software Development for the LOBO, the TRS-80 workalike. We developed the version of CP/M Plus that Gary Kildall (the owner of Digital Research, inventors of CPM (see here (http://www.cadigital.com/kildall.htm)), called the best implementation ever done.

Long after that Cobalt Systems (before Sun bought them) considered us the largest of the independent support companies supporting the RaQ and Qube line; they even gave us hardware so we could continue to supporl their new models. (Okay, I'll stop now :) ).

My points before about your script system were:
a) I felt that it should be developed by DA themselves
DA is not a large company with endless resources. I'm happy to be able to help them as I am able, and I'm happy to put my work into the Open Source community so they and others may benefit from it.

b) I think using FTP to transfer the files is a bad idea because it requires:
i) an FTP daemon to be added to the secondary DNS box
As I mentioned above, it doesn't.

ii) FTP accounts and cronjobs to be setup
iii) FTP is an insecure protocol
I agree with both of the above but don't see the issue as strongly as you do. Nevertheless I like the idea of using scp as an option.

For me personally, I think I'm going to develop a PHP script that uses the DA API and updates named.conf accordingly (see my above post).
Works for me :) . If you put it into Open Source I'll probably want to try it.

Sorry for any misunderstandings.
I'm happy for the opportunity to clear the air.

Jeff

[thoroughfare]

Thanks Jeff, I'm glad we worked that out :)

I'm 18 in 6 days, been working with PCs since a young age (I was coding in QBasic at the age of 8). I run a webhosting business but also work as a freelance graphic designer and applications developer.

I'm quite new to *nix (although I run RH9 on my desktop now, and OpenBSD on a dev server for my designs), so my knowledge often has holes, which I'll be the first to admit :D

Thanks Jeff,
Matt :)

[nobaloney]

My oldest kid is 38, so that makes me old enough to be your grandfather :) .

I'm 60 years young; my youngest kids are my godkids, ranging in age from 4 to 27. I'm trying to encourage Jesse (he's just turned 14) to get interested in the business so I can retire :) .

As you might imagine, I've been doing this stuff since long before you were born :) .

I don't know if you followed the Gary Kildall link or not; I know most of the people mentioned, and even the author of the piece (and even, a long time ago in a universe very far away, knew Bill Gates, but we were both much younger then).

And I also know how Gary died; I wasn't there but a mutual friend confirmed it for me; it was the barroom brawl.

And I got a call this evening from an old friend who worked on the original OS for the DEC PDP-10 (he was written up in Who's Who for his work on it); he tells me there never was a VMS for the PDP-10. I didn't think so.

For those nostalgia buffs; the original Compuserve Information Systems forums (CIS / now Compuserve Interactive Services, a division of AOL/compuserve.com), the first forum services anywhere, were built on DEC PDP-10s.

(The guy who wrote the CIS forum software for them also wrote the same for the TRS-80 Model I, I modified it to avoid the TRS-80 string compression timeout problem, and used it to run "The fastest board in the West" in 1978-1980.)

Jeff

[existenz]

Of course you (or DA) must create a primary zone on the master server.

Thousands of BIND admins currently use scripts to replicate the information to the slave server so they don't have to create new zones on the slave server; all my small project is, is an attempt to create a small Open Source solution anyone can use.


How does your script know what server has a slave zone? In our example we 3 dedicated DNS boxes but each machine that does virtual hosting also has the secondary for the domains that server hosts. So how do I tell it what server to update or update from?

[nobaloney]

Your question confuses me a bit; sorry.

A slave server can update itself from either a master server or a slave server, since both are equally authoritative.

When setting up the slave server using my (still proposed only) script, you'll have a config file in which you'll put the name and ftp/scp login details of each master server you want to get master zones from.

What else am I missing in your question?

Thanks.

Jeff

[TheBear]

Hello,

Just to throw a suggestion in, Webmin has the ability to create a bind slave zone on a second server - I do believe the second server must be running Webmin as well.

I only mention this as a suggestion to look at how another product does it. Not trying to get into the middle of a debate (I am not a php or C coder so I certainly wouldn't be writing such a tool).

Personally, I would like to see this ability without requiring that I be running DA on the second server. For me this is due to me most likely wanting to run a lower powered box to be a secondary DNS and backup mail server vs. a full fledged hosting box.

[redeye]

Any progress on this, because i'm running my server without slave :( and can't go into production, to riscy. I'm hoping that there will be an beta release to test with soon. :) :) :) :) ;)

[nobaloney]

What are your circumstances, Redeye?

Do you own two servers? Or do you need someone else to run slave DNS for you?

If you own two servers, are both running DA?

Jeff

[redeye]

I own a few servers (all linux), where one off them is a new webserver with da. I want to configure an other own server to be backup, but, that's my problem, i'm new to this, so a scripted solution would be great. I read you story, and thought, jippie :)

I'm about to step into commercial webhosting from virtual to a own dedicated webserver, so backup ns, would be smart i think ;).

[nobaloney]

We don't have anything ready yet :( .

But surely you can manage slave DNS manually in the meantime.

Or get someone to offer you slave DNS at no charge.

Or buy a commercial solution :) .

Jeff

[redeye]

Originally posted by jlasman
But surely you can manage slave DNS manually in the meantime.
Jeff

That's my problem I can't find any specific howto's on Bind slave dns with good examples, only general dns stuff.

Could some please post a working example? Please.

[nobaloney]

Books are wonderful teachers :) .

I highly recommend either the latest edition of "DNS and BIND", published by O'Reilly or "Linux DNS Server Administration" published by Sybex.

That said, look for the new How-To I've just written in "How-Tos".

I really don't have much time right now; I have a data center trip and a business trip to Los Angeles scheduled today), so if there's something in my "How-To" that doesn't look right to you, please bring it to my attention by a reply to the How-To, in the How-To thread; I might have made a typo.

Jeff