Dynamic DNS on Fedora Core 1

by Derek Pienaar on March 30, 2004

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.

General & Feedback:

• When making use of the examples, remove any leading spaces.
• I am no BIND expert and will appreciate any corrections or recommendations on this HOWTO be sent to me personally. Baring in mind that the idea is to keep it simple to read and follow.
• If more info is required, I recommend the BIND 9 Administrator Reference Manual.
• In this document the words daemon and service are referred to interchangeably.
• DNS and DHCP are assumed to be installed on the same server.
• Replace the neccessary values to fit your environment, for example domain.com must be replaced with your own domain name in all configs and relevant filenames.
  

Preparing:

Two packages are required for DDNS to work: dhcp & BIND. To determine whether they are installed, issue:

$ rpm -qa | egrep "^bind|^dhcp"

Three packages should list as installed:

dhcp-3.0p12-x
bind-utils-9.2.2-x
bind-9.2.2-x

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
# yum install bind

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.

DHCP Config:

## /etc/dhcpd.conf ##
########################### START ################################
# The crucial line for successful DNS updates when dhcp lease is
# renewed. Dont move further below.
ddns-update-style interim;
# Turn on DDNS.
ddns-updates on;
ddns-ttl 30;

# Confirm this to be the authoritative dhcp server for range.
authoritative;

# The secret key also defined in the BIND named.conf. Used to
# ensure authenticity of hosts allowed to update DNS records.
include "/etc/rndc.key";

# Options for the listed subnet, including address range to
# lease out & gateway address.
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.3 192.168.0.30;
option routers 192.168.0.1; #Gateway address for clients.
option broadcast-address 192.168.0.255;
option domain-name "domain.com";
option domain-name-servers 192.168.0.2; #use comma to add more.

# Force the client to release any current IP it might "own" before
# satisfying request for a new one.
one-lease-per-client on;

# Allow only server to update records based on hostname passed by
# client
deny client-updates;
default-lease-time 259200; #3 Days
max-lease-time 432000; #5 Days
}
############################ END ##################################
###################################################################

The above dhcpd.conf example will assign the following information in addition to an IP address:
Broadcast Address: 192.168.0.255
Netmask: 255.255.255.0
Default Gateway: 192.168.0.1
DNS Server: 192.168.0.1
Default Lease Time: 3 Days
Maximum Lease Time: 5 Days
Before going any further, test your dhcpd setup by starting the service:

# /etc/init.d/dhcpd start

A green “OK” message should appear. If not, first fix any errors before proceeding. If it started successfully, stop the dhcpd service prior to configuring BIND in the next section.

Named Config:

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.

/*
* ## /etc/named.conf ##
* For more info on any statement used herein, please see the
* "BIND 9 Administrator Reference Manual", freely available online
*/

acl dhcp-srvr { 192.168.0.1;};
options
{
directory "/var/named";
};

include "/etc/rndc.key";

controls {
inet 0.0.0.0 port 953
allow { 127.0.0.1; } keys { rndc-key; };
};

  zone "."
   {
   type hint;
   file "named.root";
};

  zone "domain.com" {
   type master;
   allow-update { dhcp-srvr; };
   file "domain.com.zone";
};

  zone "168.192.in-addr.arpa" in {
   type master;
   allow-update { dhcp-srvr; };
   file "domain.com.rev";
};
/* ############################# END ################################
*/ ##################################################################

Regarding rndc & dnssec keys:

Some newcomers to BIND sometimes get mixed up between the two different security key mechanisms used by BIND.

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

include "/etc/rndc.key"

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:

# chown named:named /etc/rndc.key /var/named -R

dnssec:
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.

Configure Zone files:

Zone files are used to define most of the information for a domain. They are typically used to:
1. Map host names to IP addresses (and vice versa).
2. Identify the mail servers for a domain.
3. Provide a number of other domain information.

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":
(All hostnames ending with a `.' is an exact hostname, whereas everything without one is referred to the value of the $ORIGIN directive. In our example, this value is set to "domain.com.")

Remember 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.

;########################### START ################################
$ORIGIN .
$TTL 3600           ; 1 hour
domain.com              IN SOA dns.domain.com. admin.domain.com. (
                          1       ; serial
                          3600    ; refresh (1 hour)
                          900     ; retry (15 minutes)
                          3600000 ; expire (5 weeks 6 days 16 hours)
                          3600    ; minimum (1 hour)
)
                        NS dns.domain.com.
$ORIGIN domain.com.
$TTL 3600           ; 1 hour
dns                     A      192.168.0.1
;############################# END ################################
;##################################################################

Let's 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.

;########################### START ################################
$ORIGIN .
$TTL 3600           ; 1 hour
168.192.in-addr.arpa    IN SOA admin.domain.com. dns.domain.com. (
                          1       ; serial
                          3600    ; refresh (1 hour)
                          900     ; retry (15 minutes)
                          3600000 ; expire (5 weeks 6 days 16 hours)
                          3600    ; minimum (1 hour)
)
                        NS dns.domain.com.
$ORIGIN 0.168.192.in-addr.arpa.
1                       PTR    dns.domain.com.
;############################# END ################################
;##################################################################

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:

;############################ START ################################
$TTL 86400
$ORIGIN localhost.
@ 1D                    IN SOA @ root (
                          1       ; serial (d. adams)
                          3H      ; refresh
                          15M     ; retry
                          1W      ; expiry
                          1D )    ; minimum

1D                      IN  NS @
1D                      IN  A  127.0.0.1
;############################# END ################################
;##################################################################

Configure start/stop services:

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.

To see if the named service starts without error and test your BIND configuration, start the named service:

# /etc/init.d/named start

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
# chkconfig --level 35 named on
# reboot

Test server setup & configure clients:

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
# pgrep -l named

If the services started successfully, you will get a response of process ID number and service name for each of the commands.

regarding journal files:

• Once the first dynamic update has been made, a corresponding journal file is created for the zone in /var/named.
• Journal filenames correspond to zone filenames. In our example these journal files are called domain.com.zone.jnl & domain.com.rev.jnl.
• A journal file maintains all recent DNS updates. Therefore current record updates aren't reflected immediately in the original zone file.
• The updated entries in the .jnl file are written to the zone every 15 minutes or so and just before the server is rebooted.
• Journal files are in binary format, and not to be edited by hand...ever.
• If a change needs to be made to a dynamic zone, do it as follows: Shut down the server using "rndc stop". After the rndc service has been stopped, remove the zone's .jnl files and manually edit the zone file. Restart the service with "rndc start" or reboot the server. It is important that the .jnl files be removed otherwise the manual change will not be present in the journal (because it’s still using the old .jnl files), making .jnl and zone file contents inconsistent.

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:

nameserver 192.168.0.1
domain domain.com

No 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.

For 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.

Credits:

Many thanks goes out to:

• Du-wayne Rood for he's unending patients and willingness to help when in need. You've inspired me to do the same by writing this.
• All the column and contributing authors at fedoranews.org. You have been of great help with your easy to follow HOWTO's and guides. Keep it up.
• Mark Coetser from etech for he's contribution.
• Marc Silver for he’s input.
• The South African GLUG: to subscribers always willing to assist.
• The users from channel fedora on freenode.net

Closing words

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.

Warm regards.
Derek Pienaar.