|
| |
|
|
|
|
Usage Guide for version 0.67
Contents:
Program Information
DNSMan is a web-based dns zone manager that runs on any unix platform with
a CGI-capable webserver (such as Apache), BIND 8/9, and perl installed.
It allows for the creation, modification, and delete of forward and reverse zones.
Edit Configuration Menu:
The Configuration menu allows you to set the defaults that will be filled in
when creating and modifying zones. They can be overridden during the
creation/modification process. Required fields are indicated in bold text.
Later fields in bold denote distinct sections.
Refresh method:
killall should be fine on most platforms, use pid-file for
platforms like OpenBSD that don't support killall. Solaris users should use
pid-file as well, on Solaris killall will kill ALL processes.
Always show Master dialog, Timeouts dialog, and Nameserver dialog:
When set to no, will hide the corresponding dialog text boxes when creating a zone.
The default values (from Edit Configuration) will be automatically inserted.
Auto-refresh named:
This will cause DNSMan to automatically send a SIGHUP
to named every time you modify or create a record. There's no probably no
reason not to use this as it maintains the named memory cache.
Auto-update serial:
If yes, DNSMan will increment the serial number of the record every time you
modify a record. If the serial is of the format YYYYMMDDRR where RR is the revision
number, the serial will be updated to reflect the current date and revision 01, or
if the record has already been edited today the revision will be incremented by 1.
If the serial doesn't fit the afore-mentioned format or the serial is greater than that
fitting the current date, the serial will just be incremented by 1.
This is generally a good thing since slave nameservers are notified of updates
each time the serial increases.
Note: Having this on will automatically update the serial when reverse
zones that have forward mappings are $INCLUDEd in a forward record and when adding
single records to a zone. It will set the default when editing records to
updating but can be checked off.
Appearance:
Set the size of the edit box here. The default size is 80 columns, 24 rows.
Secondary Updating:
Secondary updating allows you to create records on your secondary servers at the
same time that you create records on the master server.
Using DNSMan to do Secondary Updating:
To configure secondary updating on the master server, set Secondary Updating to
yes, fill in the master server's ip, and the values for the slave server.
The web directory is the directory off your http root, i.e. dnsman/ if dnsman is
at http://myhost/dnsman
Setting up the secondary servers requires a copy of DNSMan (master and secondaries
should have the same version installed) to be running on the secondaries.
You need to go thru Edit Configuration on the
secondary servers, but setting Secondary Updating to yes is not required.
When you finish creating a zone on the master server, there will be a link entitled
"Update to Secondary" that will send the changes to the secondary when clicked.
Using AutoDNS to do Secondary Updating:
AutoDNS is a program that uses PGP/GPG signed emails to add domains on remote servers.
DNSMan can generate AutoDNS emails to send to specified addresses following the
creation of zones. This is a good choice if you feel more secure using PGP signed
emails than the DNSMan method of updating secondary servers, need to add domains to
a server that doesn't have DNSMan installed, or need to update a server under another
person's control. Please note that PGP has not been tested, the AutoDNS program
itself only works with GPG, however PGP may work fine in DNSMan.
The target email values correspond to the address where add requests will be sent,
the PGP key id to name or email address for the user sending the emails, the PGP key
password to the passphrase to unlock the key, and the keyring location to the
directory where the public and private keys are stored. The PGP version determines
which PGP implementation to use, only GPG has been tested (as it is the only version used
by the AutoDNS program) but other versions should work.
For more information, see the file INSTALL.SECURITY that is included with DNSMan.
Security Features
.htaccess Access Restrictions:
The old ip access restrictions are deprecated. The features listed here replace
the old functionality.
Access restrictions are implemented using the .htaccess file located in the
directory where DNSMan is installed. .htaccess allows you to restrict access so
that only users who come from the specified hosts or have a valid username/password
pairs to access the program.
(For more info see:
http://www.apacheweek.com/features/userauth )
By username/password:
The interface is fairly self explanatory. Type in a username and repeat the desired
password twice and click Allow User Access. That user with be added to your htpasswd
file (DNSMan will read this from .htaccess, it can use old htpasswd files or it uses
.htpasswd by default). At this point, you will no longer be able to access the files
in the DNSMan directory without a valid username and password.
To remove a username from the list, select it and click Remove User Access. To change
the password, select the username from the list and enter the new password twice and
click Modify User Password.
By IP/hostname:
You can allow connections from specified hosts, so that they will be able to access
the page without entering a username and password. Hosts can be entered by IP or
DNS hostname. If you use the DNS hostname, the reverse DNS entry for the host must
match the hostname you enter. Hosts that are not listed will not be able to gain
access unless they have a username and password, so be sure not to add some sort of
access for yourself first.
About .htaccess:
.htaccess acts as the control for both of these features. If you lock yourself out,
either modify or delete the .htaccess file in your DNSMan directory. DNSMan will
automatically delete the .htaccess file when all username and host entries have been
removed. This will result in an unprotected system, so please be aware of this.
It will create a .htaccess file when you create a username or host entry if
necessary. The location of the username file is stored on the AuthUserFile line in
.htaccess, if you have an existing file, make sure it has the correct permissions if
you want DNSMan to use it.
Creation of forward zones
Use Add Zone to create forward zones.
Required Fields
Required fields are domain, and ip address of main host (indicated in bold).
If the record filename box is not filled in, the filename will generated from the
name of the domain.
IP Address
The ip address of main host sets the address of main host for domain.com.
Internal/External Views
Bind 9 supports the concept of views, where you can have the
nameserver return different results based on the ip address of the client.
This can be used to have different information for an internal network.
To use views, set Named version to Bind 9 in the config menu and configure at
least one view in named.conf. When you go to create a zone, there will be an option
to Assign to view. Selecting Default
View will place the zone outside of the views and give it whatever properties are the
default.
Auto CNAMEs
If you leave any of the www, ftp, mail, or smtp targets blank,
they will be filled in as CNAME records pointing to the main entry of
domain.com. Filling in ip addresses for these hosts will override the CNAME's or
the default behavior may be overridden in the Zone Creations Defaults section
of Edit Configuration.
Extra Hosts
Additional hosts can be created by filling in Extra Name and IP Address/Hostname.
Executing commands on record creation:
If you fill in this box in the Edit Config menu, you will have the option to execute
a system command after creating the zone. This can be used to send emails, run
scripts for activating web sites, etc. It is best to specify the full path to the
command because the path in the webserver may not include all the intended directories.
DNSMan recognizes several codes that will automatically be substituted if they appear
in the text box (the values come from the corresponding zone creation fields).
DOMAIN substitutes the domain name, IPADDRESS substitutes the main address for the
domain, and FILENAME substitutes the full path to the zone record file.
DNSMan will execute and and print its results on the same screen as the zone create
results page.
Future versions of DNSMan will support a pseudo-chroot environment. Commands will
not be executable when chroot is enabled.
Creating the record
To generate a new record from these settings, click on Create.
It will bring up a page where you can preview and modify the new record.
NO changes will be written until you click Write In Stone on the
preview page. After clicking, the record will be written and a status message will
be displayed. If Auto-refresh named is not on, you will want to refresh the
database manually in order to have named pick up the changes.
Secondary Updating
If you have Secondary Updating on,
you will be given the option to send the record to your secondary servers by
clicking on Update To Secondary. The results of the Secondary Update will appear
in a new window. You will need to refresh the database on the secondary (if automatic
updating is not turned on) before the record will appear.
Creation of slave zones
Slave Zone is used to create a zone that pulls it's information from a master server.
By default, creating a slave zone will add an entry to named.conf that will trigger
an AXFR (zone transfer) request to the master server. AXFR's contact the master
server and download a copy of the dns record to the slave server. For this reason,
DNSMan does not create a zone file for slave zones. After the initial transfer, the
master and slave will communicate periodically and send updated copies of the zone
file to the slave.
"Slurping" from the master
In some cases it may not be possible to do a zone transfer, because the server does
not allow or support AXFR. One alternative is to use the slurp feature built into
DNSMan which will query the master server and attempt to construct a copy of the
zonefile. To enable this, set Query master and generate zonefile to "yes" in the
Master server information of the Edit Configuration page. One caveat: if, after
the initial creation of the zonefile, AXFR is unavailabe, the zonefile will not be
updated. Other alternatives like rsync or scp may be more secure and appropriate.
Creation of reverse zones
Use add a new reverse zone to create reverse zones.
The reverse zone creator allows you to create PTR records for your ip addresses.
It also can create the forward A records that correspond to the reverse records.
Required fields are Start IP, Stop IP (last number to create a record for,
often 255), HOST, and DOMAIN.
Leaving the record filename blank will make it default to IP3.IP2.IP1.in-addr.arpa,
based on a start IP of IP1.IP2.IP3.IP4. The target of the PTR records can be
changed using Format of hostname. Leaving it blank will create records that point
to HOST-IP1-IP2-IP3-IP4.DOMAIN where each of those values will be filled in with
the corresponding value.
You can reorder this however you like to get your desired hostnames. For example,
for a start ip of 10.20.30.1, HOST foo, DOMAIN bar, and format IP3.IP4.HOST.DOMAIN,
the records will point to 30.1.foo.bar, 30.2.foo.bar, etc. If using custom
formatting, make sure to include IP4 or otherwise all the PTR's will point to only
one A record!
Corresponding forward records: You can create A records that correspond to
your new reverse entries by specifying a Corresponding forward dns file. This file
can then be included in an existing zone (my recommendation) or in a separate zone
file. If you choose separate zone, you will need to add the SOA and named.conf
entries yourself.
All of this may be a bit confusing so here is an example:
You are creating reverse records for the 1.2.3.0 class C network (255 addresses).
You choose to use the default format.
Your HOST is webservers and DOMAIN is isp.net. You choose a
corresponding forward file called webservers-isp.net and then set add forward file
to domain using $INCLUDE to "yes", and leave name of domain file blank for default
(isp.net). This will produce a reverse file full of PTR records that point to
webservers-1.2.3.1.isp.net and a forward file full of A records that take
webservers-1.2.3.6.isp.net, etc. and point them to 1.2.3.6, or whatever the
appropriate 4th octet may be. A single line reading
$INCLUDE /etc/namedb/mstr/webserver-isp.net.dns (or similar name) will be added to
the end of the isp.net file. This will add all the A records in webservers-isp.net
to the records already in isp.net
Clicking on Create will bring you to preview screen where you can view and modify
the reverse and forward records before you write them to disk. When you are
satisfied with the records, click Put It In Reverse and the records will be written
and a status page will come up. If Auto-refresh named is not on, you will need
to refresh the database in order to have named pick up the changes.
If you have Secondary Updating on, you will be given the option to send the record
to your secondary servers by clicking on Update To Secondary which will also display
a status page. Refresh the database on the secondary as well.
Modification and deletion of zones
Use Modify Records to modify or delete zones.
Selecting the domain:
To make changes to a record, either select the domain from the pulldown menu or enter in
the domain name in the text box next for Enter Domain Name (the text box will be used if
both are selected). The way that the text box works is that when you click on a button,
if there is only one domain in named.conf that contains the pattern you enter, the page
for that button will be brought up. If more than one domain matches, the matching
domains will be listed and clicking on one will bring up the page for the button you
originally. What this basically does is make the Enter Doman text box into a search
function.
Editing/Viewing a Record:
Clicking edit will opens the record in a text window where it can be edited.
When you are done, click Do the Math and the changes will be written to disk.
You will see a copy of the new record. If you check Update Serial, the serial number
will be automatically updated. If Auto-refresh is enabled, the record will be reloaded,
otherwise you need to refresh named manually.
If you click View instead of Edit, a read only copy of the record will be printed on the
screen.
Editing/Viewing named config file:
Clicking Edit named.conf will open your named configuration in an edit window. You can
make changes here and click Make It So to rewrite the config file. The new version of the
config file will be displayed. Clicking View named.conf will also display a read-only
version of the config file.
List Domains:
List Domains will list all the domains in named.conf that contain the pattern entered in
the Enter Domain Name box. Clicking on the domain will bring up an Edit box for that
domain.
Deleting Records/Zones
To delete a record or zone, select the domain name as shown above.
Clicking on Delete Zone will print the contents of the record along with it's
named.conf config file entry. Clicking "Kill It" will permanently remove the record file
and its config file entry.
Adding Single Records
First, select/enter the domain of the record you want to add to and click Add Hosts.
In the text boxes, enter the hosts you want to add. To add a host, all the boxes on that
row need to be filled in. When you have filled in all the hosts you want added, click
Add Some Hosts. You will see a status report telling you how many hosts were added and
the updated dns file will be displayed.
Refreshing the database
The database can be refreshed by clicking "refresh db" at the top of an page or Reload
named now after modifying a record. This will load new changes you have made into named's
cache. You should generally do this after every record addition.
This can now be automatically done by setting auto-refresh named to yes in the
configuration menu.
|
|
|
|
|