Starting out as a linux systems admin, I found the fact that there were few
strait-forward guides available on setting up Dynamic DNS a bit frustrating.
I am writing this in hope of it being a help to anyone in need of setting up DDNS but not
sure where to start. The guide is not meant to be exhaustive, but
rather used to get a working DDNS config up and running with as little hassle as possible.
Two packages are required
for DDNS to work: dhcp & BIND. To determine whether they are
Three packages should list as
If not, install them by
making use of yum if your repositories have been set
up, else from your Fedora CD with the rpm
command. I recommend taking the time to
set up a repository, its well worth the effort. Alexandre de Abreu has a great tutorial on this.
To install the packages with yum: ("su -" for permissions to install)# yum install dhcp
The second command will automatically install bind-utils as well if it’s not present. BIND needs it as a dependency. We will now set up the configuration files for dhcp and BIND. Do modify the files as needed to suite your environment. Both files need to be located in /etc.
message should appear. If not, first fix any errors before proceeding.
started successfully, stop
the dhcpd service prior
to configuring BIND in the next section.
Next we create the config file for BIND which is called named.conf (short for "name daemon"):
Dynamic updates are enabled on a per-zone basis by including an allow-update clause in the zone directive. To secure the updating of client records more, one can make use of TSIG keys. This is done by using the dnssec-keygen utility to generate a secret and insert it with a "key" statement in named.conf or any host you want permitted to update records on the server. These steps are not covered in this HOWTO, but very well documented in the "BIND 9 Administrator Reference Manual".
In this example we allow only the dhcp server (127.0.0.1) to make DNS updates. As the dhcp server always keeps track of addresses and will update DNS anytime it assigns an address to computers on your network. It is also more secure than allowing your clients to update their own records./*
newcomers to BIND
sometimes get mixed up between the two different security key
One of them is used to secure the controlling of the BIND daemon(rndc). This is accomplished by generating (with rndc-confgen) a unique key which is used as a password between the BIND server and other hosts on your network from where a systems admin can control the rndc daemon. (Almost always the local server) Before we discuss the next mechanism, a bit more info on rndc:
The rndc (/usr/sbin/rndc)tool is used to control the BIND daemon. rndc has builtin functionality that involves the use of secret keys. This can aggravate one due to the fact that getting even a bit of this or any key wrong will cause the mechanism to fail. The key you generate needs to be included in both the dhcpd.conf & named.conf files with an include statement:
The key secret is included
in both conf files by using the above statement as a security measure. Remember permissions on the rndc.key and /var/named
file must be owned by named:named.
Also ensure that only named:named has rw
access to the rndc.key file and remove all other
permissions. To change the owner permissions on the rndc.key
file and ensure file and owner
permissions are correct on the /var/named
directory, execute the following
command as root:
Although I am including a brief overview of this mechanism, neither the steps nor method are covered in this HOWTO. This feature and many others are well documented with good examples in the BIND 9 Administrator Reference Manual.
Overview: The dnssec utility generates a key which is used to secure the update of DNS records in a zone to authorized hosts. If you decide to make use of this mechanism you need to generate a key with the dnssec-keygen, and update the zones you wish to make use of in named.conf, and dhcpd.conf or any other hosts you want to be able to update the dnssec signed zone. In essence what dnssec does is to provide a form of authentication so that the DNS server will know when it can trust a dynamic update request.
Zone database files
are created manually and are stored in /var/named. For each zone to be
acknowledged and served by BIND, an entry must exist in the named.conf
file. We've already done this. Typically two zone files will be created
for every domain listed. One for forward & one for reverse lookups.
The first one is used
for forward lookups (map hostnames to ip address) and is called a
forward zone file. The next is called, you guessed it... the reverse
zone file which is used for reverse lookups (ip address to hostnames).
We have to manually create a working config for each of these. These
files are to be located in /var/named and must correspond with the
"file" directive value used in named.conf. In our example the forward
lookup file is called "domain.com.zone" and the reverse lookup file is
called "domain.com.rev" (Check the corresponding name in named.conf)
When your DDNS setup is finished, the client records are added
automatically to both the forward and reverse zone files when dhcp
hands out the address.
The serial number of a zone file is used as a simple version control system. This must be incremented each time the zone file is modified. Some system admins prefer an yyyymmddrr format as the serial format where rr is the number, and incremented each time the zone file is updated.. In our example we simply use a decimal value.Herewith the (forward) Zone file called "domain.com.zone":
to configure the e-mail address in the SOA record for your DNS
administrator by replacing "admin" with the correct email alias and
domain.com with your domain name. The `@' in the e-mail address is
replaced by a `.' This is by
design, so don't change it.
look at the reverse zone file called "domain.com.rev" next. Once again
replace "admin" with the email address of your DNS administrator but
leave the `.' in place.
There are two additional zone files which must always be present is the localhost.zone file for the loopback interface which is used for example when a program does a query on the localhost name. And the named.root file which is a server list that points to the root BIND servers for the internet. Also sometimes referred to as the "hints" or "named.ca" file. The latest version of this file needs to be downloaded from ftp://ftp.internic.net/domain and moved to /var/named.
localhost.zone: Provides information for the loopback iface. Used for example when a program does a query on the localhost name.The localhost.zone file:
As mentioned in the rndc section, the BIND daemon is controlled via the rndc utility. This is usually done via 127.0.0.1. We use the standard init script that calls the rndc utility to perform the actions you instruct it to do.
see if the named service starts without error and test your BIND
configuration, start the named service:
Don't get too excited yet if an “OK” message appears. To ensure the service started faultless, check the /var/log/messages file. There should be no errors about missing files that is referenced in the named.conf file. Troubleshooting any errors is easier by making use of the# tail -f /var/log/messages
command in one console and stop/start the named service in a different console. The tail command used as above will cause all new log entries to be shown on the screen as they are written to /var/log/messages, making it easier to troubleshoot any errors.
After resolving any named errors and the service starts without any errors written to the log file, we need to configure dhcpd and named daemons to start automatically at boot time:# chkconfig --level 35 dhcpd on
The server will reboot after the last command. To ensure the daemons started without intervention, log in and execute the following commands to confirm this:# pgrep -l dhcpd
the services started successfully, you will get a response of process
ID number and service name for each of the commands.
Before testing your
configuration, ensure your own DNS settings on the server or whichever
machine you will be testing from has its domain suffix configured
correctly. On Fedora and most Linux distributions this is accomplished
by simply inserting the following two lines into your /etc/resolv.conf
and of course
substituting the domain value for your own:
reboot is needed and the change is effective is immediately. Also
ensure that your linux clients are configured to obtain a DHCP address.
Use the netconfig utility to configure this.
windows clients, enable dhcp and tick "Register
this connection's addresses in DNS" and optionally "Use this connection's DNS suffix in DNS
registration" if using a notebook which might be connected to
more than one domain. Both of these settings are configured from the
Properties of "Local Area Network Connection" > "Internet Protocol
(TCP/IP)" > Properties > "Advanced" tab > "DNS" tab.
I hope this HOWTO has
been of some help. I would love to hear your story, I can be contacted
@ derekp at discovery.co.za.
Thank you for using
this guide, if you enjoyed the style this was written in and think
there is something else worth creating an HOWTO on, mail me.