The Shed is going Social! Join us on FaceBook and Twitter and chime in on the conversation.
|
 |
|
Dev Shed Forums
> System Administration
> DNS
|
Updating DNS Dynamically w/ PHP
Discuss Updating DNS Dynamically w/ PHP in the DNS forum on Dev Shed. Updating DNS Dynamically w/ PHP DNS forum discussing issues, servers, and configurations. The Domain Name System (DNS) is what the Internet uses to translate website names into IP addresses.
|
|
 |
|
|
|
|

Dev Shed Forums Sponsor:
|
|
|

November 7th, 2001, 10:29 PM
|
|
Junior Member
|
|
Join Date: Nov 2001
Location: NY (USA)
Posts: 2
Time spent in forums: < 1 sec
Reputation Power: 0
|
|
Updating DNS Dynamically w/ PHP
I am about to start an indepth project for the company I work for. We want to use a PHP front end and be able to make updates to DNS dynamically.
I was wondering if I can get some opinions on where to start.
Also, what I should use... (ie, nsupdate.c, etc.)
Any help would be appreciated.
Thanks in advance.
|

November 8th, 2001, 08:34 AM
|
|
Contributing User
|
|
Join Date: Jan 2001
Posts: 5
Time spent in forums: < 1 sec
Reputation Power: 0
|
|
>> get some opinions on where to start
Start learning Perl. PHP, often installed as mod_php, is not capable to perform sysem task to automate update, unless you change the file permission (insecure) to be writable by the user Apache runs as.
Start here -> http://forums.devshed.com/showthrea...23249&forumid=6
|

November 8th, 2001, 10:37 AM
|
|
Junior Member
|
|
Join Date: Nov 2001
Location: NY (USA)
Posts: 2
Time spent in forums: < 1 sec
Reputation Power: 0
|
|
|
One more question...
What if I used PHP to interact with shell scripts?
Would that be a good solution?
|

November 8th, 2001, 12:36 PM
|
|
Contributing User
|
|
Join Date: Jan 2001
Posts: 5
Time spent in forums: < 1 sec
Reputation Power: 0
|
|
|
>> What if I used PHP to interact with shell scripts?
Your shell/CGI scripts written in Perl must then be setuid root.
>> Would that be a good solution?
PHP is not a good solution in the first place. And whatever frontend doesn't make any difference, since those scripts are not doing the actual works anyway.
Anyhow, do not change whatever file permission from 644 to 646 or 666 to make it writable by the user Apache runs as.
|

November 26th, 2001, 02:07 AM
|
 |
Banned ;)
|
|
Join Date: Nov 2001
Location: Woodland Hills, Los Angeles County, California, USA
|
|
|
The way we handled this problem was as follows:
Version 1:
We kept all our domain information in a SQL server database and when I first joined our company, my co-workers and I knew very little perl. So I wrote a Delphi program to query the database and write out all the data into the dns files. The Delphi program would then zip all the files and ftp the data over to the linux boxes and then send a request to a perl program that was listening on a specific port for a command from a specific IP. The perl program on the other end would unzip the files, convert CR/LF to LF in all the files, rebuild the .cf file and then restart named. Even though my co-worker and I knew very little perl at that time, we managed to hack some pretty decent working code using the Perl Cookbook and a few hours of elbow grease. Note that if someone tried to connect to the port from a different IP, the perl script would disconnect the connection immediately. In version 1 of the program, the Delphi program would ftp the zip file to one name server, send the perl program the appropriate command and then wait 15 mins or so before going to the next name server (assuming that the perl script + named took 15 mins to reload all the data). This is a bad idea if named takes more than 15 mins to restart, but we kept increasing the time delay in the Delphi code, as the number of domains increased.
Version 2:
We got better at perl and discovered how to make perl on *nix boxes connect to SQL Server on Windows. So we modified the perl script as follows: All the Delphi program did now was connect on the specific port and send the appropriate command to the perl script. The perl script would then connect to the SQL server and build all the dns data by itself. This saved us the time taken by the previous version to zip up and ftp the files over. After creating the necessary files, the perl script would then restart the name server. My buddy found a way (highly incompatible) to also determine when named was done reloading the data by monitoring the CPU activity! So the perl script would restart named and monitor the CPU load till named was done reloading. Then it would send back a response to the Delphi program saying that named was ready to recieve queries. The Delphi program would then send the command to the next name server. Thus we didn't have to depend upon guessing a delay time before sending the command to the next name server. This scheme's been working well for us for at least 1.5 years!
Hope this helps.
Last edited by Scorpions4ever : November 26th, 2001 at 02:11 AM.
|

November 26th, 2001, 03:57 AM
|
|
Contributing User
|
|
Join Date: Jan 2001
Posts: 5
Time spent in forums: < 1 sec
Reputation Power: 0
|
|
|
Why bother going thru all these troubles when there is a better named alternative - tinydns (in djbdns package)?
tinydns is highly secure, efficient and reliable. Writing a script to do dynamic updating is as easy as writing a "Hello World" script.
|
Developer Shed Advertisers and Affiliates
| Thread Tools |
Search this Thread |
|
|
|
| Display Modes |
Rate This Thread |
Linear Mode
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|
|